home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group98a.txt / 000098_icon-group-sender _Thu Mar 5 08:20:56 1998.msg < prev    next >
Internet Message Format  |  2000-09-20  |  5KB
  1. Return-Path: <icon-group-sender>
  2. Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239])
  3.     by baskerville.CS.Arizona.EDU (8.8.7/8.8.7) with SMTP id IAA29020
  4.     for <icon-group-addresses@baskerville.CS.Arizona.EDU>; Thu, 5 Mar 1998 08:20:56 -0700 (MST)
  5. Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM)
  6.     id AA07306; Thu, 5 Mar 1998 08:20:55 -0700
  7. From: gep2@computek.net
  8. Date: Wed, 4 Mar 1998 21:10:40 -0600
  9. Message-Id: <199803050310.VAA24705@axp.cmpu.net>
  10. Mime-Version: 1.0
  11. Content-Type: text/plain
  12. Content-Transfer-Encoding: 7bit
  13. Subject: Re: Icon translation
  14. To: icon-group@optima.CS.Arizona.EDU
  15. X-Mailer: SPRY Mail Version: 04.00.06.17
  16. Errors-To: icon-group-errors@optima.CS.Arizona.EDU
  17. Status: RO
  18. Content-Length: 4089
  19.  
  20. > Frankly, I think one of the weaknesses of Icon is the lack of strong
  21. typing - or what more accurately I would call "optional strong typing".
  22. Icon already has declarations - they're just not used for data types.  I
  23. could imagine an Icon-like language that differed *only* in having
  24. optional type declarations, with an "any" type that behaves just as Icon
  25. variables now do.  Such a language would, of course, have all the
  26. elegant Icon syntax and control structures.
  27.  
  28. > Strong typing would achieve two things: it would provide protection
  29. against a wide class of coding errors...
  30.  
  31. Well, if you're going to create the ugly thing that is strong typing in an 
  32. effort to "provide protection against a wide class of coding errors" then I 
  33. don't think it truly makes sense to stop at just whether something is numeric or 
  34. string.
  35.  
  36. The really serious way to protect against this type of coding errors involves 
  37. providing more complex rules regarding what kinds of values belong in a data 
  38. item... such as:
  39.  
  40.   * contains a number between 1 and 7
  41.  
  42.   * contains a string matching an entry in table T1
  43.  
  44.   * contains a year (e.g. 1980-2060)
  45.  
  46.   * contains a month number (1-12)
  47.  
  48.   * contains a string matching either "*" or a key in ISAM file Y
  49.  
  50. Of course, it's generally easy enough to code up rules like that if you WANT 
  51. them... exactly like it being easy enough to code up type checking stuff, IF you 
  52. want it. 
  53.  
  54. > ...and it would make efficient compilation possible without elaborate and 
  55. still incomplete dataflow analysis to determine run-time types.  
  56.  
  57. There's nothing wrong with the "efficiency" of Icon's compilation... the 
  58. compiler is VERY quick, in fact.
  59.  
  60. Personally, I don't think that the big problem to the acceptance of Icon has 
  61. anything to do with its execution speed... sure, faster is most always better, 
  62. but I think there are other issues which ought to be addressed first.
  63.  
  64. > And were it optional, what would be lost?
  65.  
  66. Mainly, the OTHER things that could be done in less or equivalent development 
  67. time and which would go a lot further toward helping make Icon a more useful 
  68. programming tool.  For example:
  69.  
  70.    * ISAM file support and/or database-like features (named fields in disk file 
  71. records for example).  Either as a built-in, or even just as an interface to an 
  72. existing database system (FoxPro, Access, Clipper, whatever).  This would allow 
  73. Icon to have access to databases used in other pre-existing systems, and would 
  74. allow programs to be written and database structures and relationships changed 
  75. without invalidating previously written programs not using the new fields.  
  76. Business use of programs (and most others too, in truth) almost universally 
  77. requires efficient ISAM files and/or database access, and Icon presently doesn't 
  78. really have it.
  79.  
  80.    * Improved support for using Icon for CGI scripting... for example, being 
  81. able to load and keep in memory a single, reusable copy of the interpreter so 
  82. that the only file needing to be fetched for executing a CGI script being the 
  83. (tiny) icode file.  Or providing the necessary hooks to facilitate sending and 
  84. receiving E-mail, accessing news and FTP and Web servers, and the like.
  85.  
  86. > I won't claim that such a language would be Icon; only Icon is Icon.
  87. But it's the language I'd very much like to have.
  88.  
  89. I think that strong and fixed typing is a plague, largely perpetrated by those 
  90. who haven't ever discovered the advantages of a programming language which HELPS 
  91. you rather than throwing rocks into your path.  Of course, I realize that there 
  92. is no accounting for taste... I guess we'll just have to agree to disagree on 
  93. this point.
  94.  
  95. > By the way, were Icon++ (or Icon--, if you prefer) to be compiled into C
  96. (the poor man's form of compilation), I would expect that it would *not*
  97. use the C string type because of the problems with null characters.
  98.  
  99. Absolutely... the C string type is nearly useless for Icon's purposes.  (And in 
  100. fact, isn't even all that great for C's purposes!)
  101.  
  102. Gordon Peterson
  103. http://www.computek.net/public/gep2/
  104. Support the Anti-SPAM Amendment!  Join at http://www.cauce.org/
  105.  
  106.